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/ \ REASONS FOR REVIEW 

&) In a Final Office Action dated January 19, 2006 (the "January 19 Final Office 
..on"), the Examiner rejected Claims 1-19 and 22 under 35 U.S.C. §1 02(e) as being 
anticipated by U.S. Patent No. 6,725,272 issued to Susai et al. ("Susai"). Applicant 
respectfully submits that the Examiner made a clear error in relying on Susai as an 
anticipatory reference as Susai clearly fails to disclose or teach several claim limitations. 

The claims of the present application address storing and providing inquiry data 
corresponding to a target device. As discussed in the July 15, 2005 "Reply to Office 
Action Dated 4/15/05" (the "July 15 Reply") on pages 8-9, inquiry data is not simply data 
stored on a device, but is data corresponding to the target device (i.e., data about the 
target device) and an inquiry command or a request for inquiry data is a request for the 
data corresponding to the target device. Embodiments of the present invention include 
systems and methods that provide for caching of inquiry data so that the inquiry data can 
be served from the cache (e.g., by a router) if, for example, the target device is busy and 
cannot respond to the request. 



Claims 1 and 22 

Claim 1 recites: 



A method of using a router to cache inquiry data corresponding 
to a target device in a network having a plurality of client devices, the 
method comprising: 

storing inquiry data corresponding to a target device in a cache 
memory; 

receiving a request for the inquiry data corresponding to the target 
device; 

reading the inquiry data from the cache memory; and 
providing the inquiry data corresponding to the target device in 
response to the request. 

The recited invention, according to Claim 1, performs the steps of "storing inquiry 
data corresponding to a target device", "receiving a request for the inquiry data", 
"reading the inquiry data from the cache memory" and "providing the inquiry data 
corresponding to the target device." Claim 22 includes similar recitations. Thus, when 
a request for inquiry data corresponding to a target device is received, the request can 
be serviced from cache memory rather than forwarded to the target device. 
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Susai has nothing to do with caching inquiry data corresponding target devices 
that can served in response to requests for the inquiry data. Instead, Susai deals with 
redirecting requests to an on-hold server that, much like a telephone on-hold system, 
serves arbitrary content until the request can be serviced by the target of the request. 

The Examiner cites Fig. 2, column 4, lines 16-33; and column 5, line 66 through 
column 6, line 17 as showing each of the claim limitations. See, January 19 Final Office 
Action, pages 3-4. FIGURE 2 simply shows a network diagram. See, Susai, FIGURE 
2. Column 4, lines 16-33 of Susai states: 



FIG. 2 is a network context diagram for an interface unit 202 and 
an on-hold server(s) 204 according to a preferred embodiment of 
the present invention. In a preferred embodiment, interface unit 
202 is an intelligent network 'interface card with a CPU inside a 
server. Interface unit 202 can also be intelligent box sitting 
outside the server, in which case it can serve more than one 
server. Interface unit 202 can also be a load balancer, bandwidth 
manager firewall, proxy-cache, router, switch, computer system, 
or any other network device that is located between a client and 
server. In theory, on-hold server 204 represents the world's 
largest web site. Users (via clients) are temporarily redirected 
to on-hold server 204 when their requested server is too 
busy to accommodate their page requests. On-hold server(s) 
204 may be physically located within interface unit 202, may be 
an independent server directly connected to interface unit 202 or 
may be an independent server located anywhere on the Internet. 

This portion of Susai simply discusses redirecting a request to an on-hold server, 
but does not teach or suggest "storing inquiry data corresponding to a target device", 
"receiving a request for the inquiry data", "reading the inquiry data from the cache 
memory" or "providing the inquiry data corresponding to the target device." 

Column 5, line 66-col. 6, line 17 states: 



Interface unit 202 puts the client on-hold, as shown in step 310, 
and as more fully described with respect to FIG. 4A and FIG. 4B, 
below. While the client is on-hold there is no limit to the types of 
information that can be provided to the client by the present 
invention, including music, sports, news and so forth. It is 
important to note that there may be one or more on-hold servers 
204 utilized by the present invention that the client may be 
directed to. In the case of having multiple on-hold servers 204 to 
chose from, the present invention may use various factors in 
determining which on-hold server 204 to direct the client to. 
These factors may include such things as client IP address, type 
of request and on-hold server 204 load. Hence, on-hold service 
may be a distributed service. An on-hold portal by definition 
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should relinquish control to the request controller. This control 
switching is initiated by client-side intelligence (Java 
Applets/Scripts), interface memory (where the interface 
remembers the held requests) and on-hold server 204 initiated 
re-direction. The re-direction can be at the IP level or at the 
HTTP level. 

Again, this portion of Susai simply discusses redirecting a request to an on-hold 
sever that serves content while a request is on-hold. There is no teaching of "storing 
inquiry data corresponding to a target device", "receiving a request for the inquiry data" 
or "reading the inquiry data from the cache memory" or "providing the inquiry data 
corresponding to the target device" as i) the data stored by the on-hold server is arbitrary 
content and not the content that is the subject of the request and ii) the data stored by 
the on-hold server is not inquiry data corresponding to the target device. 

Indeed, Susai teaches away from responding to a request for inquiry data with 
inquiry data stored in a cache. In Susai, when a client request is ready to be taken off 
on-hold, the interface unit of Susai "translates the client request and passes it to the 
requested server." See, Susai, col. 5, lines 25-27 (emphasis added). Consequently, it 
is the target server for the request that actually provides the requested data. 

Susai, thus, teaches a system in which an interface unit 202 can receive a 
request for data from a target server. If the target server is busy, interface unit 202 can 
redirect the request to an on-hold server that serves arbitrary content until the target 
server is available it is otherwise determined that the request should be taken off on- 
hold. When it is determined that the request should be taken off on-hold, the request is 
forwarded to the target server for servicing. There is no teaching or suggestion that 
either the interface unit or on-hold server perform any of "storing inquiry data 
corresponding to a target device", "receiving a request for the inquiry data", "reading the 
inquiry data from the cache memory" or "providing the inquiry data corresponding to the 
target device." 

Claim 11 

Claim 11 recites: 

A device comprising: 

a router configured to route data between one or 

more hosts and one or more target devices; and 
a cache memory coupled to the router; 
wherein the router is configured to store inquiry data 

received from the one or more target devices 

and to provide at least a portion of the stored 
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inquiry data in response to a request for inquiry 
data corresponding to one of the target devices 
that is busy. 

Thus, according to Claim 1 1 , the router stores inquiry data from one or more target 
devices and provides inquiry data in response to a request for inquiry data 
corresponding to a target device that is busy. Again, this allows a request for inquiry 
data corresponding to a target device to be serviced by the router rather than the target 
device. 

The Examiner cites column 4, lines 16-33 and column 5, line 66 through column 
6, line 41 as disclosing "a router storing inquiry data." See, January 19, Final Office 
Action, page 7. Column 4, lines 16-33 simply describe that "users are temporarily 
redirected to on-hold server 204 when their requested server is too busy." See, Susai, 
column 4, lines 26-27. Again, according to Susai, a user request is simply put on on- 
hold. There is nothing in Susai that teaches or suggests a router that stores inquiry data 
corresponds to a target device and responds to requests for inquiry data using the 
stored inquiry data. 

Column 5, line 66 through column 6, line 41 also does not teach a router 
"configured to store inquiry data received from the one or more target devices and to 
provide at least a portion of the stored inquiry data in response to a request for inquiry 
data corresponding to one of the target devices that is busy" and, in fact, teaches the 
opposite. This section of Susai teaches that an interface unit puts the client on-hold. 
See, Susai, column 5, lines 66-67. While the client is on-hold, information can be 
provided to the client such as music, sports, news and so forth. See, id, column 6, lines 
1-4. When a client request is ready to be taken off on-hold, the interface unit of Susai 
"translates the client request and passes it to the requested server." See, id. column 6, 
lines 25-27 (emphasis added). Thus, if a requested server is busy, the system of Susai 
puts the request on-hold and provides arbitrary content to the client until the request can 
be serviced. When the request is taken off on-hold, the request is forwarded to the 
requested server such that the requested server provides the requested data . Susai 
simply does not "provide at least a portion of the stored inquiry data in response to a 
request for inquiry data corresponding to one of the target devices that is busy" as 
recited in Claim 1 1 . 
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